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Abstract: 

In an audio video interactive (AVI) receiver receiving a packet stream including 
a directory and an AVI program having an associated identifier in the directory, a 
method is disclosed for controlling the execution of the AVI program comprises 
the following steps. First, loading the AVI program into a memory in response to 
the presence of the AVI program in the packet stream. Then beginning execution 
of the loaded AVI program. And then minimizing the executing AVI program 
when a directory identifying a different AVI program is detected in the packet 
stream. 
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Description 

[0001] The present invention relates to a method for 
controlling the execution of an audio video interactive 
(AVI) executable program component. . s 
[0002] Interactive television systems have been pro- 
posed in which a television receiver includes a proces- 
sor programmable by the broadcaster and capable of 
responding to data entered by the user, generating on- 
screen graphic displays overlaid upon the broadcast 10 
video, generating sounds combined with the broadcast 
audio and/or exchanging data with the broadcaster or 
other outside data processing service. In such a sys- 
tem, the broadcast location includes a computer system 
for generating interactive application program informa- 15 
tion, including executable code and data, and combin- 
ing the interactive application program information as an 
additional component with the video and audio compo- 
nents of the associated television signal. The processor 
in the television receiver receives the interactive appli- 20 
cation program information from the broadcaster, exe- 
cutes the interactive application program represented 
by that information, generating the graphics and sounds 
to be combined with the television video and audio, and 
processing user inputs received via a remote control 25 
unit. 

[0003] Document WO 91/031 1 2 published on March 
7, 1991, concerns a video-on-demand transmission 
system in which a video program is transmitted in sev- 
eral segments' 30 
[0004] In a proposed AVI system, the composite AVI 
signal from the broadcaster is broadcast in the form of a 
packet data stream, including a plurality of time multi- 
plexed packet services. Each packet service carries a 
different component signal of the composite AVI signal. 35 
For example, one service carries the video component, 
another carries the audio component, and another car- 
ries the interactive application program information 
component. There may be still other services carrying 
stereo and SAP audio channels, and/or closed caption- 40 
ing information, etc. In addition, some packet data 
streams may include packet services carrying compo- 
nent signals for more than one AVI program. Each 
packet service has a unique service component identi- 
fier (SCID) associated with it and the packets in that 45 
packet service each include that service identifier. 
[0005] Further, in the proposed AVI system, one 
packet service carries a program guide and includes a 
predetermined service identifier. The data carried by the 
program guide packet service associates the compo- so 
nents of an AVI program with the service identifiers of 
the packet services carrying those components. Using 
this data, the packet services carrying the components 
of the desired AVI program may be extracted from the 
packet stream. 55 
[0006] The component signals in the AVI signal packet 
data stream are carried by one or more transmission 
units, each consisting of a plurality of packets. A first 



packet in any transmission unit is a header packet, and 
the remaining packets in the transmission unit are asso- 
ciated data packets. The header packet contains infor- 
mation about the following data, and the associated 
data packets carry the data making up that portion of 
the component signal. Different transmission units may 
include different numbers of data packets, and the par- 
titioning of the component signals into transmission 
units may be influenced by the timing necessary to 
deliver the different component signals to the viewer 
locations at desired times, or other real time considera- 
tions. 

[0007] The interactive application program information 
component consists of one or more code modules (con- 
taining executable code), possibly one or more data 
modules, and a directory module which includes data 
describing the code and data modules making up the 
interactive application program component. These mod- 
ules are continuously repeated in the application pro- 
gram data component flow. The modules are each 
uniquely identified, and are carried by transmission 
units, as described above, in which the header packet 
contains the identifier of the module and the location 
within that module where the data in the following data 
packets belongs. The interactive application program 
information component also includes special signal for 
controlling the execution of the AVI application program. 
For example, one signal may instruct a currently execut- 
ing AVI application program to suspend execution; 
another may instruct a currently suspended AVI applica- 
tion program to resume execution; and another may 
instruct the currently executing AVI application program 
to cease execution. These signals may be incorporated 
into signal packets within the AVI program component 
packet service. 

[0008] A processor in an AVI receiver, under the con- 
trol of the system loader, first extracts the directory mod- 
ule from the data flow, and utilizes the information 
contained in the directory to determine which code 
module is first to be executed. That code module, called 
the autostart module, is then extracted from the data 
flow and loaded into the memory. When the autostart 
module has been completely loaded into memory, the 
processor begins to execute that code module. During 
the course of its execution, that code module may 
request data from data modules identified in the direc- 
tory module. Those data modules are then extracted 
and loaded into memory. When the module has been 
completely loaded into memory, the requesting code 
module is notified, and execution continues to process 
that data, it is also possible for one code module to 
chain to a subsequent one. In such a case, the current 
code module issues a request to chain to a new code 
module listed in the directory module, and its memory 
space is freed. The requested code module is then 
extracted from the data flow, and loaded into memory. 
When it has been completely loaded into memory, it is 
executed. Other functions are possible, and will be 



2 



3 



EP0 680 213 B1 



4 



described below. 

[0009) Unlike other distributed computer systems, the 
AVI program component being received by the AVI 
receiver may change at any time. For example, an AVI 
program may be interrupted by a non-AVI commercial or 
by an AVI commercial, which, of course, includes a dif- 
ferent AVI program. Or a viewer may change channels 
from one AVI program to another AVI program. It is nec- 
essary to maintain proper synchronization between the 
AVI executable code, and the sound and graphics being 
generated by that code, and the audio and video com- 
ponents being received. 

[0010] In accordance with principles of the present 
invention, it is disclosed a method for controlling the 
execution of an audio video interactive program as 
defined in claims 1 and 6. 
[0011] In the drawing: 

FIGURE 1 is a block diagram of a portion of an AVI 
signal decoder, incorporating the present invention; 
FIGURE 2 is a software structure diagram of the 
software executed by the processing unit 40 illus- 
trated in FIGURE 1; 

FIGURE 3 illustrates flow diagrams and memory 
layout diagrams useful in understanding the extrac- 
tion of modules from the data component in an AVI 
program; 

FIGURE 4 is a diagram, partially in block form and 
partially in memory layout form also useful in under- 
standing the extraction of modules from the data 
component of an AVI program; 
FIGURE 5 is a flow diagram illustrating the initializa- 
tion function of the system loader; and 
FIGURE 6 is a state transition diagram illustrating 
the data stream monitoring function of the system 
loader. 

[001 2] FIGURE 1 is a block diagram of a portion of an 
AVI signal decoder, incorporating the present invention. 
A decoder as illustrated in FIGURE 1 is installed in each 
viewer location at which it is desired to participate in AVI 
programs. In FIGURE 1, a transport mechanism (not 
shown) is coupled to an input terminal 5 of the decoder. 
Input terminal 5 is coupled to an input terminal of a tuner 
10. An output terminal of tuner 10 is coupled to a data 
input terminal of an AVI program component detector 
30. A data output terminal of program component detec- 
tor 30 is coupled to a system bus 416 of a processing 
unit 40. Processing unit 40 includes a central process- 
ing unit (CPU) 410, a read/write memory (RAM) 412 
and a read-only memory (ROM) 414 coupled together in 
a known manner via the system bus 416. A stream I/O 
adapter 403 is bidirectionally coupled between the sys- 
tem bus 416 and a control terminal of the program com- 
ponent detector 30. 

[001 3] An audio processor 4 1 8, coupled to the system 
bus 416, provides an audio signal to AVI audio output 
terminal 25, and a video processor 420, also coupled to 



the system bus 41 6, provides a video signal to AVI video 
output terminal 1 5. Further input and output facilities are 
provided by an I/O port 422, coupled to a collocated 
local processor (not shown) via a bidirectional terminal 

5 45; user I/O adapter 424, for receiving data from a user 
via an input terminal 35; and a modem 426, coupled to 
an outside computer (not shown) via a bidirectional ter- 
minal 55; all also coupled to the system bus 416 in a 
known manner. Other equipment, e.g. math processors, 

w other I/O adapters, etc., may be coupled to system bus 
416 in a known manner. In addition, a bus extender may 
be included for coupling to other equipment in enclo- 
sures external to the decoder enclosure. 
[0014] In operation, the transport mechanism, which, 

is for example, may be a direct RF satellite link, a cable 
system feed or a fiberoptic link to the decoder, carries a 
plurality of AVI signals, any one of which may be 
selected by the user for viewing. In a direct satellite link, 
for example, a plurality of AVI data streams may be fre- 

20 quency multiplexed on the transport mechanism by 
modulating respective RF carrier signals. Each RF car- 
rier signal is rebroadcast from a respective transponder 
in the satellite to the viewer location. Tuner 10 selects a 
desired RF modulated signal, under the control of proo- 
fs essor 40, in a known manner. For example, in the direct 
satellite system, the RF modulated signal containing the 
packet services carrying the components of the desired 
AVI program signal is tuned by a known RF tuner. The 
output of tuner 10 is a baseband digital packet data 

30 stream containing those packet services. 

[0015] CPU 410 requests desired packet services 
from the program component detector 30 by writing the 
desired service identifiers and RAM 412 buffer locations 
into appropriate service component identifier (SCID) 

35 and direct memory access (DMA) controller registers in 
the program component detector 30 via the stream I/O 
adapter 408. The program component detector 30 then 
monitors the packet data stream for the desired packet 
services. When header packets from any of the desired 

40 packet services are received, they are stored in a prede- 
termined header packet buffer in the RAM 412 using 
known DMA write techniques, and a header packet 
interrupt is generated. When data packets from any of 
the desired packet services are received, they are 

45 stored in the previously specified buffer locations in the 
RAM 412 also using known DMA write techniques. 
When all the data packets in a transmission unit have 
been received, a data complete interrupt is generated. 
Reception of header and/or data packets from a packet 

so service may be enabled and disabled under control of 
the CPU 410. See U.S.-A-56 13003, PACKET VIDEO 
SIGNAL INVERSE TRANSPORT PROCESSOR MEM- 
ORY ADDRESS CIRCUITRY, by K.E. Bridgewater et 
published on March 18, 1997 (not a prior art document) 

55 for a more detailed description of the program compo- 
nent detector 30. 

[001 6] For example, when a new RF modulated signal 
is tuned by the tuner 10, the packet service containing 
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the program guide is requested by the CPU 41 0 by sup- 
plying the fixed program guide service identifier to a 
service identifier register in the program component 
detector 30. When the data in the program guide pack- 
ets has been received and stored in memory, that data 
allows the CPU to request the packet data services for 
the desired AVI program. 

[001 7] After packets in the requested packet services 
are received by the program component detector 30, 
and are written via DMA into the previously specified 
buffer locations in RAM 412, the video processor 420 
and audio processor 418 read the data from the RAM 
412 buffer locations associated with their respective 
packet services, using known DMA read techniques, 
under control of the program component detector 30. 
Video processor 420 and audio processor 418 then 
decode the compressed and encoded data to produce 
the AVI video signal at output terminal 15, and the AVI 
audio signal at output terminal 25, respectively. It is also 
possible for CPU 410 to cooperate with the video proc- 
essor 420 and/or audio processor 41 8 in the decoding 
process. The data component packet service packets 
are processed under the control of the CPU 410 in a 
manner described below. 

[0018] As described above, whenever a header 
packet from a requested packet service is received by 
the program component detector 30, it is stored in a pre- 
determined location in RAM 412 for that packet service, 
and a header packet interrupt signal is generated for the 
CPU 410. In response to the header packet interrupt 
signal, an interrupt handler is executed which analyses 
the contents of the header packet and either appropri- 
ately updates the RAM 412 buffer locations in the DMA 
registers in the program component detector 30 and 
enables the DMA transfer, or disables the DMA transfer 
if the transmission unit is not desired. Once the DMA 
transfer is enabled, the data in the data packets is then 
loaded into RAM 412 under DMA control. When the 
loading of the data packets is completed, the program 
component detector 30 generates a data complete 
interrupt signal. In response to the data complete inter- 
rupt signal, an interrupt handler is executed to perform 
"dean-up" functions and prepare for the next header 
packet. 

[0019] FIGURE 2 is a structure diagram of software 
200 executed by the processing unit 40 illustrated in 
FIGURE 1. FIGURE 2 illustrates the major software 
components making up the AVI processing multitasking 
operating system. In FIGURE 2, all the components are 
stored in the ROM 414, except the application program, 
indicated by the darken area. The application program 
is carried by the data component of the AVI signal, is 
received from the broadcast location and is stored in 
RAM 412. The software components illustrated in FIG- 
URE 2 represent executable code and associated con- 
stant data. As the code executes, it may generate and 
access variable data, which is stored in the RAM 412. 
[0020] In the proposed AVI broadcast system, differ- 



ent decoders may use CPUs using different instructions 
sets, e.g. from different manufacturers. In this system, 
the application program is processor independent inter- 
mediate code. The software in each decoder includes a 

5 component which interprets the intermediate applica- 
tion code (INTERPRETER). This enables the broadcast 
application program to be executed on decoders con- 
taining any type of CPU 410. That interpreter will read 
the AVI data component instructions in intermediate 

to code from the RAM 412, manipulate memory, and inter- 
act with the hardware through other software compo- 
nents via an application programming interface (API). 
This API, which is basically a list of subroutines availa- 
ble to an application program and the information nee* 

is essary to call them, is published and may be used by 
the application programmer to access the decoder ele- 
ments. 

[0021] A math library performs all the functions 
needed to implement integer and floating point arrthme- 

20 tic. A flow operating system controls all the drivers nec- 
essary to monitor the data component of the AVI signal, 
and process requested modules, as will be described in 
more detail below. A user interface management com- 
ponent handles all the user interaction, and utilizes a 

25 graphics library, and an event manager to communicate 
with the user. The graphics library performs all the gen- 
eration of graphic images to overlay on the received AVI 
video, and uses the math library for drawing complex 
curves. 

30 [0022] The different software components of the 
decoder software communicate with other asynchro- 
nously by sending messages to each other. Each pro- 
gram component has a message queue and operates 
by repeatedly reading the next message from the 

35 queue, processing that message, possibly sending a 
message to another program component, and, if no 
more messages are pending, waiting for the next mes- 
sage. The event manager manages the communication 
of these messages among the other software compo- 

40 nents by properly routing the messages and maintain- 
ing the message queues. 

[0023] Each hardware adapter also includes an asso- 
ciated software driver. The driver performs the actual 
interaction between the CPU 410 and the registers in 

45 the associated hardware adapter via the system bus 
416. For example, there are drivers for the modem 426, 
the external I/O port 422, the stream I/O adapter 408 
and the user I/O 424. In addition, separate drivers main- 
tain a software timer and operate the front panel of the 

so decoder. These drivers are closely dependent on the 
event manager. All of the above components use com- 
mon functions provided by a multitasking kernel. For 
example, the kernel maintains process priorities, active 
task queues, signals, semaphores, preemptive task 

55 switching clock ticks, interrupts (hardware and soft- 
ware), and process stacks. In addition, the kernel pro- 
vides hardware initialization and initiation of the first 
system task, which is a system loader. 
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[0024] At initiation, the system loader executes API 
calls to the flow operating system, which in turn calls the 
stream driver to send the appropriate data to the pro- 
gram component detector 30 via the stream I/O adapter 
408. These API calls from the system loader initiate a 
scan of the data component packet service for the direc- 
tory module in a manner described in more detail below. 
When the directory module is found, it is loaded into 
RAM 412, and checked to see if all of the required 
resources to execute that program are available. If so, 
then the system loader initiates a scan of the AVI data 
component for the first module, termed an autostart 
module, which will initiate the AVI program. When the 
autostart module is located, it is extracted from the data 
component packet service and loaded into RAM 412. 
This autostart module is in the form of intermediate 
code, and is executed by being interpreted by the inter- 
preter. The autostart module performs the remainder of 
the initialization and begins execution of the AVI pro- 
gram. This program may possibly load other code and 
data modules, and chain to another code module, all via 
API calls. In this manner, the system loader operates in 
the same manner as a classic UNIX® shell. 
[0025] In addition, the system loader continues to 
scan the data component packet service comparing 
transmitted directory modules to the current directory 
module in RAM 412. If the transmitted directory module 
is different than that stored in RAM 412, it indicates that 
the data component packet service has changed, for 
example, such as when a viewer changes channels, or 
an interactive commercial is being broadcast In this 
case, a message is sent to the application program via 
the event manager using the API. In response to this 
message, the application program deallocates all its 
resources, and maintains only a minimal presence in 
the processing element 40. For example, the memory 
used to store all code and data modules may be freed, 
and only the execution state of the application kept in 
RAM 412. When the minimization of the application pro- 
gram has completed, a message is sent to the system 
loader. 

[0026] The system loader then allocates the 
resources necessary to execute the AVI program repre- 
sented by the new directory module. When a new direc- 
tory module is detected in the AVI data component 
packet service, a list of previously minimized applica- 
tions is searched, and if the application represented by 
the new directory is present, that application is resumed 
by reloading the necessary code and data modules 
from the data component flow, and resuming execution 
from where it had previously been halted. This may hap- 
pen at the end of an intervening interactive commercial. 
This process may be recursive, where a second AVI 
program may, itself, be interrupted by a third AVI pro- 
gram, and later reactivated. 

[0027] FIGURE 3 illustrates flow diagrams and mem- 
ory layout diagrams and FIGURE 4 is a more detailed 
block diagram of the program component detector 30 



(of FIGURE 1) and a more detailed memory layout dia- 
gram useful in understanding the extraction of modules 
from the data component in an AVI program. In FIGURE 
4, the baseband digital packet stream from tuner 10 (of 

5 FIGURE 1) is coupled to respective data input terminals 
of a data DMA controller 32 and a header packet DMA 
controller 34 within the program component detector 30. 
Respective data output terminals of data DMA controller 
32 and header packet DMA controller 34 are coupled to 

w the system bus 416 of the processing unit 40, The 
stream I/O adapter 408 is coupled between the system 
bus 416 and respective control input terminals of the 
data DMA controller 32 and the header packet DMA 
controller 34. In operation, stream I/O adapter 408 sup- 

15 plies control information, e.g. buffer location start and 
end addresses, read and write addresses, and transfer 
counts, in known manner from CPU 410 (of FIGURE 1 
to the data DMA controller 32 and the header packet 
DMA controller 34. Stream I/O adapter 408 may then 

20 enable the data DMA controller 32 and/or the header 
packet DMA controller 34 to transfer data or header 
packets, respectively, from the packet stream to the 
buffer in a known manner, or disable such transfers, 
under control of the CPU 410. When the data DMA con- 

25 troller 32 completes a data transfer, it generates a data 
complete interrupt for CPU 410. When the header 
packet DMA controller 34 completes loading a header 
packet, it generates a header packet interrupt for CPU 
410. 

30 [0028] Also in FIGURE 4, the RAM 41 2 is represented 
by a large block, and data structures are represented by 
smaller blocks within the large block. The blocks in FIG- 
URE 4 are schematic only, and are not meant to illus- 
trate either absolute or relative locations or sizes 

35 allocated in the RAM 412 for the data structures. In 41 2, 
a module request queue 322, a header packet buffer 
324, a directory module buffer 326 and a module buffer 
328 data structures are illustrated. Fields of information 
within the data structures are illustrated as horizontal 

40 slices containing the name of the type of information 
contained in that field. These will be discussed in detaiJ 
below. 

[0029] FIGURE 3 illustrates the procedure followed in 
extracting a module from the data component packet 

45 service and storing it in a buffer in RAM 412. Similar 
procedures are followed for other module processing, 
as will be described below. In FIGURE 3, actions taken 
in an application program (or the system loader) are 
illustrated in the left hand column under the heading 

so "APPLN PROG.". In block 302, the application program, 
using the API, makes a request to the flow operating 
system to load a module having the identifier ID from 
the AVI program component packet service. As 
described above, API calls are basically subroutine 

55 calls to operating system functions. The program execu- 
tion is, thus, transferred to the flow operating system 
(FOS). Actions taken by the FOS are illustrated in the 
next column to the right, under the heading "FOS." 
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Because the request involves the loading of a module, 
in block 312 the FOS requests a memory allocation 
from the memory manager of sufficient size to contain 
the module. For example, if the requested module is a 
code or data module, the previously stored directory 
module 326 (of FIGURE 4) includes a field containing 
the length (LENGTH) of the module ID. In this case a 
memory manager allocates a module memory buffer 
(328 of FIGURE 4) having a starting address START 
and an ending address END. Then, in block 314, infor- 
mation describing the request, e.g. the identifier ID of 
the module, the type of request REQUEST (in this case 
a request to extract and load a module) and the allo- 
cated buffer starting address START, and ending 
address END, are all stored in the entry in the request 
queue (QUEUE) 322. The header packet DMA control- 
ler 34 is then enabled to load header packets into the 
RAM 412, when they occur in the packet stream. 
[0030] If the request is for the directory module, its 
length is not known a priori. In this case a relatively 
large memory allocation is requested. If this allocation 
turns out to be too small, the request is repeated, after 
requesting a larger memory allocation, until either the 
directory module is loaded, or it is determined that there 
is insufficient memory to load it, in which case the 
attempt to run the AVI program is abandoned. 
[0031] The FOS then immediately returns to the call- 
ing application program. The application program is 
then able to perform other processing, for example issu- 
ing requests for other modules, other initializations, etc. 
When access to the requested module is required, the 
application program, in block 304, may issue an API call 
to a wait function in the kernel. This function suspends 
the execution of the application program until a mes- 
sage indicating the successful loading of the requested 
module is received by that application program. When 
such a message is received, the application program is 
reactivated to process that message. Alternatively, the 
application program may remain active, e.g. in order to 
respond more quickly to user inputs, and periodically 
poll its message queue for the message indicating suc- 
cessful loading of the requested module, and process 
the message when it is received. 
[0032] As described above, the header packet DMA 
controller 34 loads header packets into a header packet 
(HDR PKT) buffer 324 (of FIGURE 4) in the RAM 412 
previously allocated by the memory manager, and 
issues a header packet interrupt to the CPU 410. A por- 
tion of the processing performed by the header interrupt 
handler in the kernel is illustrated in the column headed 
"HEADER INTR" in FIGURE 3. In block 332, the identi- 
fier of the module which is being carried in the transmis- 
sion unit for which this is the header packet, is retrieved 
from a known location, ID, in the header packet buffer 
324. In block 334, request queue 322 is examined to 
determine if there is a pending request for this module. 
[0033] If there is a pending request for that module, 
then, in block 336, the data packet DMA controller 32 in 



the program component detector 30 is initialized with: 
the module buffer 328 starting address START and end- 
ing address END from the request queue 322; a write 
address which is the sum of the module buffer 328 start- 

5 ing address START and the transmission unit data off- 
set OFFSET (i.e. START + OFFSET); and a last write 
address which is START + OFFSET + SIZE (or alterna- 
tively, a load count which is the size SIZE from the 
header packet buffer 324 in place of the last write 

w address). The data packet DMA controller 32 is then 
enabled. 

[0034] In block 338, rf this is the first header packet 
received after the load request was made, a pointer to 
the first write address, FIRST, stored in the request 

is queue 322, is initialized to the write address of this first 
transmission unit (i.e. FIRST = START + OFFSET ). In 
addition, a pointer to the expected next write address, 
NEXT, also stored in the request queue 322, is also ini- 
tialized to the write address of the first transmission unit 

20 (i.e. NEXT = START + OFFSET ). Other processing is 
then performed in block 338, which will be described in 
more detail below. For example, a special pointer to the 
location in the request queue 322 of the request cur- 
rently being processed, CURR REQ, is stored in a pre- 

25 determined location (not shown) in. RAM 412. Then, in 
block 339, the interrupt handler returns (339) 
[0035] The data packet DMA controller 32 initializes a 
write pointer (WP) to the previously received write 
address (START + OFFSET) and loads data from the 

30 following data packets in the AVI program component 
packet service into sequential locations in the module 
buffer 328 in RAM 412. When all the data in the trans- 
mission unit has been loaded into RAM 412, the data 
complete interrupt is generated. A portion of the 

35 processing performed by the data complete interrupt 
handler in the kernel is illustrated in the right hand col- 
umn headed "DATA COMPL INTR" of FIGURE 3. 
[0036] In block 342 clean-up functions related to the 
current status of the DMA transfer are executed. The 

40 current request pointer (CURR REQ), previously set in 
the header packet interrupt handler, points to the entry 
in the request queue 322 for which a transmission unit 
has just finished loading. The expected next write 
address pointer, NEXT, in the current request is incre- 

45 mented by the value SIZE from the header packet buffer 
324, and now points to the write address expected for 
the next transmission unit. If the new value of the 
expected next write address pointer, NEXT, is equal to 
the ending address, END, of the module buffer 328, it is 

so reset to the starting address, START, of the module 
buffer 328, in wrap-around fashion. 
[0037] In block 344 it is determined whether the entire 
requested module has been loaded into memory. The 
value of the expected next write address pointer, NEXT, 

55 is compared to the value of the first loaded address. 
START If they are the same, then the entire module has 
been loaded. In block 346, a message is sent, via the 
event manager, to the requesting application program to 
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indicate that the requesting module has been com- 
pletely retrieved, illustrated as a dashed line in FIGURE 
3. In addition, the request is removed from the request 
queue 322. If the value of the expected next write 
address NEXT is not the same as the first loaded 5 
address, START, the data complete interrupt handler 
returns (349), and the next transmission unit containing 
data for the requested module will be processed by the 
header packet interrupt handler, as described above. In 
either event, the current request pointer (CURR REQ) is w 
cleared. 

[0038] If some portion of a transmission unit is not 
properly received by the program component detector 
30, then a subsequent header packet will be received 
before the data complete interrupt signal from the pre- 15 
ceding header packet has been generated by the DMA 
circuitry in the program component detector 30. This, in 
turn, generates a subsequent header packet interrupt 
signal before the preceding data complete interrupt sig- 
nal can be generated. Processing in the header packet 20 
interrupt handler and the data complete interrupt han- 
dler can cooperate to identify this situation and provide 
for handling such an error. 

[0039] In the header packet interrupt handler, such 
processing is performed in block 338 (of FIGURE 3), 25 
after the data packet DMA controller is enabled to 
receive the next transmission unit. For each header 
packet received, the expected next write address, 
NEXT, in the current request queue entry, previously 
updated by the data complete interrupt handler, is com- 30 
pared to the write address (START + OFFSET) for the 
newly received header packet. If they are the same, the 
previous transmission unit was successfully received. If, 
however, the last ending address is not the same as the 
new offset, that means that the DMA transfer of the pre- 35 
vious transmission unit did not complete successfully. In 
this case, both the first write address, FIRST, and the 
expected next write address. NEXT, are updated to the 
current write address (START + OFFSET). That is, pre- 
viously loaded transmission units are essentially dis- 40 
carded, and loading of the module is restarted with the 
current transmission unit. This form of recovering from a 
data missing type of error may take more time, because 
a transmission unit which was previously loaded suc- 
cessfully may result in an error when reloaded. How- 45 
ever, by using this form of recovery, the tasks performed 
by the header packet interrupt handler and data com- 
plete interrupt handler are minimized, and only two 
pointers are needed in memory. 

[0040] As a part of the module complete message so 
handling, the event handler performs an error checking 
on the received module. For example, a cyclic redun- 
dancy check (CRC) code is transmitted as an embed- 
ded part of the module. The event handler calculates a 
CRC over the received module in the module buffer 328 55 
in the RAM 412, and compares it to the embedded 
CRC. If the newly calculated CRC equals the embedded 
CRC, then the module was correctly received, other- 



wise an error occurred, and the module is reloaded, as 
described above. 

[0041] When the requested module has been com- 
pletely loaded into memory further processing by the 
application module may continue, illustrated in FIGURE 
3 by inference as a line from the bottom of the API call 
to the wait function 304. However, a separate task in the 
application program may be activated in response to the 
receipt of the message from that application program's 
message queue. 

[0042] The above mentioned API includes functions 
for accessing the data stream by the application pro- 
gram, via the interpreter, or by the system loader. An 
application programmer will use the published API 
description to formulate an API call to access the 
desired data stream function. A first group of functions 
relates to the directory of modules. A first function, 
DIR_NEW is a request for a new directory. As described 
above, in response to this API function, an allocation of 
memory is made, then a request is enqueued for the 
loading of the next directory module in the data stream, 
then the API function returns. When the directory has 
been loaded, a message is sent to the requesting pro- 
gram. Another function DIR_FREE, frees the memory 
space taken by the current directory. The function 
DIR_SELECT indicated which directory module will be 
used in subsequent API calls. The function 
DIR_CURRENT returns a handle to the currently 
selected directory. 

[0043] The functions DIR_SPY and DIR_STOP_SPY 
are similar to the DIR_NEW function. In response to a 
DIR_SPY API call, a request is enqueued in the request 
queue for a directory module, but instead of loading a 
directory module and sending a message when it is 
loaded, this function sends a message whenever a 
directory module is detected in the data flow (the direc- 
tory module is not loaded). In addition, the request 
remains in the request queue until a DIR_STOP_SPY 
API call is made. When a DIR_STOP_SPY API call is 
made, the request queue is searched for the directory 
spy request, and that entry is removed. These functions 
are useful in spying any change from the current direc- 
tory in the data stream. Finally there are API calls to 
extract information about the current directory: 
DIRJDENTIFIER, DIR_REQUIREMENT and 
DIR_NB_MODULES. 

[0044] Because of the embedded CRC code in the 
module, any memory allocation request for loading a 
module must take this code into account. Three API 
ca|ls are provided to handle this. The function 
MODULE_ALLOC takes a module identifier as an argu- 
ment and requests an allocation of the proper amount of 
memory to load that module, taking into account any 
CRC or other memory requirements. The function 
MODULE_FREE frees the memory taken by a module. 
MODULE_CHECK performs a CRC check of a loaded 
module and returns the result. This may be performed 
at any time because the CRC is embedded in the mod- 
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ule as loaded in memory. 

[0045] Another set of API calls deals with the mod- 
ules, using the currently selected directory to identify 
them. There are API calls to extract information about a 
module; MODULE_REQUIREMENT. MODULE_SIZE 
and MODULE_FLAGS. These enable the system to 
determine whether a module may be loaded and/or exe- 
cuted. The function MODULE_RUN is used to load an 
executable module, as described above, create a new 
process, and begin execution at the entry point of the 
module. This function is used by the system loader to 
initiate AVI program execution. The function 
MODULE_CHAIN is used to load a subsequent execut- 
able module, end execution of the current module, and 
begin execution of the newly loaded module at its entry 
point. No new process is created in this case. The func- 
tion MODULE_LOAD is used to load a module, but not 
start execution. As described above, a message is sent 
to the requesting program when the module loading has 
completed. The function MODULE_EXEC is used to 
create a new process and begin execution of a module, 
which was previously loaded by the MODULEJ.OAD 
API call, at its entry point. 

[0046] The function MODULEJJNK executes a new 
module using the current process, resources and varia- 
bles. It allows for subroutine-like calls from within a mod- 
ule by providing a dynamic link to the new module. This 
permits AVI programs to be divided into smaller mod- 
ules which may be dynamically linked only when neces- 
sary. The MODULEJJNK function maintains relocation 
and jump tables. The functions MODULE_SPY and 
MODULE_STOP_SPY operate similarly to the 
DIRECTORY_SPY and DIRECTORY_STOP_SPY but 
with respect to identified modules. The MODULE_SPY 
API call inserts an entry in the request queue including 
the identifier of the module. Whenever a header module 
with the same identifier is detected in the data stream, a 
message is sent to the requesting program. This contin- 
ues until a MODULE_STOP_SPY API call is made. In 
response to the MODULE_STOP_SPY API call, the 
entry containing the spying request for the identified 
module is removed from the request queue. The 
MODULE_STOP_LOAD function stops any module 
loading request currently in process and removes the 
loading request entry from the request queue. The func- 
tions FLOWJ/IESSAGE and FLOW_STOP_MESSAGE 
respectively generate and remove a request for a mes- 
sage when a special signalling packet, relating to the 
data stream occurs, such as a suspended data flow or 
the end of the data flow. When such an event occurs, a 
message is sent to the requesting program. 
[0047] As described above, the system loader, per- 
forms system initialization and monitors the data stream 
to ensure that the execution of the application program 
is in synchronism with the received audio and video 
components. FIGURE 5 is a flow diagram illustrating the 
initialization function of the system loader In block 52 of 
FIGURE 5, various hardware and software components 



of the decoder (of 17) are initialized. In addition, loca- 
tions in the RAM 412 are allocated and initialized for 
various data structures. These initialization functions 
are well known, and depend upon other software com- 

5 ponents in the decoder. A system programmer will 
understand what hardware and software initializations 
are required, what data structures are required, and 
how to perform the initializations. Thus, this block will 
not be described in detail below. 

w [0048] In block 54 a DIRJslEW API call, described 
above, is made This API call loads the next directory 
module appearing in the AVI program component 
packet service into an allocated buffer in the RAM 412. 
This API call returns to the system loader immediately, 

is even though the directory may not be loaded into the 
RAM 412 until a later time. The system loader performs 
other functions and then, if necessary, a wait API call 
(not shown) until a message is received, via the event 
manager, indicating that the directory module has been 

20 loaded. In block 56, the resources available in the 
decoder (of FIGURE 1) are compared to the data indi- 
cating the required resources, in the directory module. If 
the decoder has sufficient resources to execute the AVI 
program, a MODULE_RUN API call is made to load the 

25 autostart code module, identified in the previously 
loaded directory module, as described above. Again, 
the API call returns immediately, but the code module 
may not be completely loaded from the data stream until 
some later time. After the autostart code module is com- 

30 pletely loaded, another task is created in a known man- 
ner using the multitasking kernel for executing the AVI 
program, via the interpreter. 

[0049] In block 58, the system loader begins to moni- 
tor the AVI program component for execution signals, 

35 and directory changes, and controls the execution of the 
AVI program by sending messages to the AVI program 
as described below. FIGURE 6 is a state transition dia- 
gram illustrating the monitoring function of the system 
loader, and is useful in understanding the operation of 

40 the system loader. If a directory is detected in an AVI 
program component packet service, then the program 
that the viewer has selected is an interactive program. 
Once the directory has been loaded into the RAM 412, 
and the autostart code module requested from the AVI 

45 component packet service, the AVI program, under the 
control of the system loader, enters the INACTIVE state 
61. In the INACTIVE state 61, all the resources to start 
the application have been allocated and the application 
may be partially or completely loaded, but there is no 

so interaction with the viewer. For example, while the auto- 
start module is being loaded, the AVI program remains 
in the INACTIVE state 61. In addition, even after the 
autostart module has been loaded, the viewer may 
merely be changing channels through the channel car- 

55 rying the AVI program and have no intention of interact- 
ing with the AVI program. Or the viewer may just wish to 
observe the AVI program before making a decision to 
join the interaction. In all these cases it is important that 
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the remote control acts in a normal channel changing 
mode and not in an interactive mode. This is the pur- 
pose of the INACTIVE state 61. In order to notify the 
viewer that the channel being watched is broadcasting 
an interactive program, a special interactive program § 
logo or icon is overlaid upon the AVI video. 
[0050] In order for a viewer to actually begin to interact 
with the AVI program, a special key, called "ACTIVATE 
KEY" below, is provided on the remote control. When 
the interactive program logo or icon is displayed, the 10 
viewer may press the ACTIVATE KEY. The system 
loader, in response to the ACTIVATE KEY press, sends 
an ACTIVATE message to the AVI program which, then, 
enters the ACTIVE state 63. In the ACTIVE state 63, the 
interpreter actually begins to execute the previously is 
loaded AVI program at its entry point. When the auto- 
start module of the AVI program begins execution, it 
allocates and initializes its own data structures in the 
RAM 412, loads other code and/or data modules and 
controls all user actions from the remote control and 20 
front control panel. 

[0051] Because the AVI program controls all user 
interaction, it can prevent the user from changing chan- 
nels or performing other normal remote control func- 
tions. In order to revert to normal remote control 25 
functions, the viewer must first stop the current AVI pro- 
gram. The viewer presses the ACTIVATE KEY, again, to 
deactivate the program. In response to this key press, 
the system loader sends a DEACTIVATE message to 
the executing AVI program, which, then, leaves the 30 
ACTIVE state 63, and returns to the INACTIVE state 61 . . 
Again, the special interactive program logo or icon is 
displayed, indicating that the AVI program is loaded but 
not executing. The viewer may, then, change channels 
or perform other normal remote control functions, or 35 
may reactivate the AVI program by pressing the ACTI- 
VATE KEY again. The ACTIVATE KEY, thus, acts as a 
toggle to switch between the ACTIVE state 63 and the 
INACTIVE state 61 when it is pressed. The ACTIVATE 
and DEACTIVATE messages may also be thought of as 40 
ACTIVATE TOGGLE messages, whose meaning (ACTI- 
VATE or DEACTIVATE) depends upon the state of the 
AVI program (INACTIVE or ACTIVE, respectively) when 
the ACTIVATE KEY is pressed. 

[0052] While the AVI program is executing in the 45 
ACTIVE state 63, there are times when it is desired to 
suspend its execution. For example, when a non-inter- 
active commercial is to be transmitted, the transmitted 
audio and video will no longer match the sound and 
graphics being generated by the decoder 10 (of FIG- so 
URE 1), and it is desired to allow the viewer to use the 
remote control in its normal manner. The application 
programmer, however, cannot know in advance when 
such suspensions will be required. Thus, in this case, 
the broadcaster, independent of the AVI program, may 55 
repetitively include special signal packets (as described 
above), called suspend signal packets, in the AVI pro- 
gram component packet service. Each such packet con- 



tains data directing that the currently executing AVI 
program is to suspend execution. 
[0053] The system loader, via a FLOW_MESSAGE 
API call, receives a message whenever such packets 
are recognized in the AVI program component packet 
service. For example, when a suspend signal packet is 
received, the system loader receives a suspend signal 
message, and, in response to the first suspend 'signal 
message, sends a SUSPEND message to the AVI pro- 
gram, which, in turn, suspends execution, entering the 
SUSPENDED state 65. In the SUSPENDED state 65, 
execution of the AVI program halts in such a manner 
that it may be started again from the point where it was 
suspended. That is, all the resources necessary to exe- 
cute the AVI program remain allocated, and the execu- 
tion state of the AVI program is stored in a location in the 
RAM 412. In addition, a second logo or icon, indicating 
that a previously executing interactive program is sus- 
pended, but ready to resume when allowed, is overlaid 
over the current video image. 
[0054] When the interruption (e.g. non-interactive 
commercial) is over, the broadcaster stops including the 
suspend signal packets in the AVI program component 
packet service. The system loader, after a predeter- 
mined period of time without receiving a suspend signal 
message, sends a CONTINUE message to the AVI pro- 
gram, which, in turn, resumes execution from where it 
was previously suspended, entering the ACTIVE state 
63, described above. 

[0055] An alternative embodiment of the SUS- 
PEND/CONTINUE signalling arrangement, described 
above, is for the broadcaster to include a single sus- 
pend signal packet in the AVI program component 
packet service when it is desired to suspend execution 
of the AVI program. The broadcaster, then, includes 
another special signal packet, called a continue signal 
packet, in the AVI program component packet service 
when it is desired to resume execution of the AVI pro- 
gram. This packet contains data directing the currently 
suspended AVI program to resume execution. The sys- 
tem loader recognizes the continue signal packet, and 
sends a CONTINUE message to the AVI program, 
which resumes execution and enters the ACTIVE state 
63, as described above. 

[0056] It is also possible for a viewer to stop the exe- 
cution of a suspended AVI program. When the program 
suspended logo or icon is displayed, the viewer may 
press the ACTIVATE KEY. The system loader, respon- 
sive to this key press, sends a DEACTIVATE message 
to the suspended AVI program, which in turn, enters the 
INACTIVE state 61, described above. From the INAC- 
TIVE state 61 , the program may only resume execution 
when the viewer presses the ACTIVATE KEY, causing 
the system loader to send an ACTIVATE message to the 
AVI program, which will, then, enter the ACTIVE state 
63. If the system loader is still receiving suspend signal 
packets, another SUSPEND message is immediately 
sent to the AVI program which, again, enters the SUS- 
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PENDED state 65. Tne INACTIVE state 61, ACTIVE 
state 63 and SUSPENDED state 65 are the states 
among which the AVI program may switch in response 
to messages sent to it from the system loader. However, 
there are two other states which are entered under the 5 
direct control of the system loader. 
[0057] An AVI program can reach an end of its execu- 
tion. For example, the broadcaster may include another 
special signal packet, called an end execution signal 
packet, in the AVI program component packet service. 10 
The system loader receives an end execution message 
when an end execution signal packet is recognized in 
the AVI program component packet service, via the 
FLOW_MESSAGE API call. In response to the end exe- 
cution message, the system loader sends an EXIT mes- is 
sage to the AVI program. Regardless of what state the 
AVI program is in, INACTIVE 61, ACTIVE 63 or SUS- 
PENDED 65, the AVI program responds to the EXIT 
message by deallocating all its resources, and removing 
all record of itself from the decoder 10 (of FIGURE 1). 20 
The program is deemed to have entered the HALTED 
state 69, and disappears from the decoder 10. In some 
cases, the program itself can recognize that its execu- 
tion has reached an end, either via a user command, or 
by its own execution. When the AVI program recognizes 25 
that its execution has ended, it performs the same 
processing that it would have performed had an EXIT 
message been received, and it enters the HALTED 
state 69 on its own accord. 

[0058] When an AVI program is in the SUSPENDED 30 
state, it is possible that a different interactive AVI pro- 
gram will be received on the AVI program component 
data flow. For example, if the AVI program was sus- 
pended for a commercial, that commercial may itself be 
an interactive program, or the user may have changed ss 
channels to a channel broadcasting a different AVI pro- 
gram. In both these cases, the new AVI program will 
include a directory module, which is different from that 
for the suspended AVI program. 

[0059] The system loader, via the DIR_SPY API call. 40 
receives a message whenever a directory is detected in 
the AVI program component packet service. The system 
loader compares the currently active directory to the just 
detected directory. When the system loader recognizes 
that a different directory is present in the AVI program 45 
component packet service, it begins to load the AVI pro- 
gram represented by that directory. 
[0060] First, a message is sent to the currently sus- 
pended AVI program to indicate that the program com- 
ponent packet service no longer is broadcasting its so 
program, or that the program has lost the flow.' This 
message is a request for the currently executing pro- 
gram to minimize itself, i.e. is a MINIMIZE message. In 
response to the MINIMIZE message, the currently sus- 
pended AVI program first stores its current execution ss 
state and environment in a small block of the RAM 412 
containing the identification of the AVI application, and a 
time duration, which will be described below. Then the 



suspended AVI program begins to deallocate is 
resources. A minimized AVI program does not include 
any code, and, thus, cannot change states in response 
to messages, or restart itself. 
[0061] The system loader then loads the newly 
detected directory and autostart module and places the 
new AVI program in the INACTIVE state 61 displaying 
the interactive program logo or icon, as described 
above. The viewer can then start and stop interaction 
with this new AVI program by pressing the ACTIVATE 
KEY. and the program may, itself be suspended and 
continued. 

[0062] The minimizing process is a recursive process. 
For example, this new AVI program, if suspended, may 
also be minimized if yet another AVI program is 
detected in the AVI program component packet service. 
In this case, another block of memory is allocated, and 
the execution state and environment of this AVI pro- 
gram, along with its identifier and a time duration, is 
stored in this memory block. Then the newly detected 
AVI program is loaded, as described above. The 
number of programs which may simultaneously be min- 
imized is limited only by the amount of memory required 
to store all the memory blocks containing the executions 
states and environments of the minimized programs. 
[0063] If there is not enough available memory space 
to load the new directory module, or execute the pro- 
gram represented by a previously loaded directory mod- 
ule, and if there are memory blocks allocated 
representing minimized programs, the system loader 
may automatically deallocate some or all of the memory 
blocks according to an algorithm (such as deallocating 
the oldest memory block first, or first deallocating mem- 
ory blocks marked as expendable by the originating 
application) in an attempt to derive sufficient memory 
space. Alternatively, the system loader may present a 
list of minimized applications to the viewer, and allow 
the viewer to select some or all for deletion. Blocks rep- 
resenting selected minimized applications are then 
deallocated to derive sufficient memory space. 
[0064] In the meantime, the memory blocks containing 
the execution states and environments of previously 
minimized AVI programs remain allocated in memory. 
As described above, there is a time duration in each 
such memory block. If the time duration in any block is 
exceeded, then that previously minimized AVI program 
times out. In this case, that program is considered to 
have entered the HALTED state 69, and its block of 
memory containing the execution state and environ- 
ment is deallocated, and all record of that previously 
minimized AVI program is lost. 
[0065] However, it is possible for the decoder 10 to 
again receive an AVI program component containing 
the directory, code and data modules of a previously 
minimized AVI program, or for that AVI program to 
'regain the flow.* For example, the interactive commer- 
cial may have terminated, entering the HALTED state 
69, or the viewer may have changed the channel back to 
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this channel. The system loader begins to toad the 'new* 
directory in the AVI program component packet service. 
Whenever a new directory is loaded, the application 
identifier is compared to the identifiers in all blocks con- 
taining execution state and environments currently $ 
stored in the RAM 412. If a matching block is found, 
then the code and data modules are loaded, and the 
AVI program placed in the INACTIVE state 61, but its 
execution state is updated to that just before it was min- 
imized. When the viewer presses the ACTIVATE KEY, 10 
the AVI program enters the ACTIVE state 63, and 
begins execution where it previously left off. In this man- 
ner, an AVI program may be temporarily stopped to run 
another AVI program, and then resumed, without requir- 
ing sufficient resources for both programs to remain in 15 
memory simultaneously. 

Claims 

1. Method for controlling the execution of an audio 20 
video interactive (AVI) program in an audio video 
interactive receiver receiving a packet stream 
including a directory and an AVI program having an 
associated identifier in the directory, comprising the 
steps of: 25 

loading the AVI program into a memory (328) in 
response to the presence of the AVI program in 
the packet stream; 

beginning execution (63) of the loaded AVI pro- 30 
gram; 

monitoring the packet stream for an AVI pro- 
gram different from the executing AVI program; 
and 

interrupting (65) and minimizing (67) the 35 
resources allocated to executing the AVI pro- 
gram when said AVI program different from 
said AVI program is detected in the packet 
stream, and wherein minimizing includes 
removing said executing AVI program from said 40 
memory (328). 

2. The method of claim 1, wherein the step of inter- 
rupting and minimizing the executing AVI program 
comprises the steps of: 45 

suspending execution of the AVI program; 
storing the identifier of the AVI program in a 
block of memory; and 

storing the execution state and environment of so 
the AVI program at the time of suspending exe- 
cution, in said block of the memory. 

3. The method of claim 2, wherein the step of loading 

the AVI program comprises the steps of: 55 

loading an AVI program in memory; 
searching previously stored blocks of memory 



for a block containing an identifier matching 
that of the loaded AVI program; and 
if there is a matching memory block, setting the 
execution state and environment of the loaded 
AVI program to the execution state and envi- 
ronment for the corresponding AVI program 
stored in said block of memory. 

4. The method of claim 3, further including: 

after said setting step, holding loaded said AVI 
program in an inactive state until activation by 
user input. 

5. The method of claim 4, further comprising the step 
of displaying an interactive program indicator which 
indicates that an AVI program is loaded but not exe- 
cuting. 

6. Method for controlling the execution of the AVI pro- 
gram in an audio video interactive (AVI) receiver 
receiving a packet stream including an AVI program 
and execution signals, comprising the steps of: 

loading the AVI program into a memory in 
response to the presence of the AVI program in 
the packet stream; 

beginning execution of the loaded AVI pro- 
gram; 

monitoring the packet stream for special signal 
packets; and 

halting execution, and unloading the executing 
AVI program from the memory in response to 
detection of a special signal packet containing 
an end execution signal. 

7. The method of claim 6. further including the steps 
of: 

suspending execution of the AVI program in 
response to a suspend execution signal in the 
. packet stream, wherein suspending execution 
includes storing the execution state of the AVI 
program being suspended and dumping the 
AVI program from memory; and 
continuing execution of a previously sus- 
pended AVI program in response to a continue 
execution signal in the packet stream, wherein 
continuing executing includes reloading the 
previously suspended AVI program from data 
in said packet stream and presetting execution 
states with data stored when the previously 
suspended AVI program was suspended. 

8. The method of claim 7, wherein the suspend execu- 
tion signal in the packet stream is represented by 
repetitive suspend execution signal packets during 
a suspend time interval, and the continue execution 
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signal is represented by a cessation of said repeti- 4. 
tive suspend execution signal packets. 

Patentanspruche 

5 

1. Verfahren zur Steuerung der Ausfuhrung eines 5. 
interaktiven audio/video (AVI) Programms in einem 
interaktiven audio/video Empfanger zum Empfang 

eines ein Verzeichnis und ein AVI Programm mit 

einem assoziierten Identifikator im Verzeichnis ent- w 6. 

haltenden Paket-Stromes, bei dem 

das AVI Programm in einen Speicher (328) 
geladen wird in Abhangigkeit von der Gegen- 
wart des AVI Programms im Paket-Strom; is 
die Ausfuhrung (63) des geladenen AVI Pro- 
gramms begonnen wird; 
der Paket-Strom auf ein vom ausfuhrenden AVI 
Programm verschiedenes AVI Programm uber- 
wacht wird; 20 
der der Ausfuhrung des AVI Programms zuge- 
ordnete Zuflufi unterbrochen (65) und mini- 
miert (67) wird, wenn das von einem 
ausfuhrenden AVI Programm verschiedene 
AVI Programm im Paket-Strom detektiert wird, 25 
wobei die Minimierung die Entfernung des 
durchfiihrenden AVI Programms aus dem 
Speicher (328) einschlieBt. 

7. 

2. Verfahren nach Anspruch 1 , bei dem der Schritt der 30 
Unterbrechung und Minimierung des ausfuhrenden 
AVI Programms folgende Schrrtte enthait: 

Unterbrechung der Ausfuhrung des AVI Pro- 
gramms; 35 
Speichern des Identifikators des AVI Pro- 
gramms in einem Speicherblock und 
Speichern des Ausfuhrungsstatus und der 
Umgebung des AVI Programms im besagten 
Speicherblock zur Zeit der Unterbrechung der 40 
Ausfuhrung. 

3. Verfahren nach Anspruch 2, bei dem der Schritt des 
Lad ens des AVI Programms die folgenden Schritte 
enthait: 45 

Laden des AVI Programms im Speicher; 

Suchen zuvor gespeicherter Speicherblocks 

nach einem Block, der einen dem geladenen 

AVI Programm entsprechenden Identifikator so 8. 

enthait, und 

Setzen des Ausfuhrungsstatus und der Umge- 
bung des geladenen AVI Programms auf den 
Ausfuhrungsstatus und die Umgebung des ent- 
sprechenden, im besagten Speicherblock 55 
gespeicherten AVI Programms, wenn ein ent- 
sprechender Speicherblock vorhanden ist. 



Verfahren nach Anspruch 3, bei dem nach dem 
Setzen das besagte AVI Programm in einem inakti- 
ven Status geladen gehalten wird, bis eine Aktivie- 
rung durch eine Benutzer-Eingabe erfolgt. 

Verfahren nach Anspruch 4, bei dem ein interakti- 
ver Programm- Indikator angezeigt wird, wenn ein 
AVI Programm geladen, aber nicht ausgefiihrt ist 

Verfahren zur Steuerung der Ausfuhrung des AVI 
Programms in einem interaktiven audio/video (AVI) 
Empfanger, der einen ein AVI Programm und Aus- 
fuhrungssignale enthaltenden Paket-Strom emp- 
fangt, bei dem 

das AVI Programm in einen Speicher geladen 
wird in Abhangigkeit vom Auftreten des AVI 
Programms im Paket-Strom; 
die Ausfuhrung des geladenen AVI Programms 
begonnen wird; 
• der Paket-Strom auf spezielle Signalpakete 
uberwacht wird und 

- die Ausfuhrung angehalten und das ausfuh- 
rende AVI Programm aus dem Speicher entla- 
den wird, in Abhangigkeit der Oetektion eines 
speziellen Signalpakets, das ein End-AusfQh- 
rungssignal enthait. 

Verfahren nach Anspruch 6, bei dem 

- die Ausfuhrung des AVI Programms in Abhan- 
gigkeit eines Ausf uh rungs- Unterbrechung s- 
Signals im Paket-Strom unterbrochen wird, 
wobei das Unterbrechen der Ausfuhrung die 
Speicherung des Ausfuhrungsstatus des unter- 
brochenen AVI Programms enthait und das 
Entladen des AVI Programms aus dem Spei- 
cher, und bei dem 

die Ausfuhrung eines zuvor unterbrochen en 
AVI Programms fortgesetzt wird in Abhangig- 
keit von einem Ausfuhrungs-Fortsetzungssi- 
gnal im Paket-Strom, wobei die Fortsetzung 
der Ausfuhrung das erneute Laden des zuvor 
unterbrochenen AVI Programms aus Daten 
des Paket-Stroms einschlieBt sowie das Vor- 
Einstellen der Ausfuhrungs-Zustdnde mit den 
bei der Unterbrechung des zuvor unterbroche- 
nen AVI Programms gespeicherten Daten. 

Verfahren nach Anspruch 7, bei dem das Ausfuh- 
rungs-Unterbrechungssignal im Paket-Strom repra- 
sentiert wird durch wiederholte Ausfuhrungs- 
Unterbrechungs-Signalpakete in einem Unterbre- 
chungszeitintervall, und bei dem das AusfOhrungs- 
Fortsetzungs-Signal reprasentiert wird durch ein 
Aussetzen der wiederholten Ausfuhrungs-Unter- 
brechungs-Signalpakete. 
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Revendications 

1 . Precede destine k commander ('execution d'un pro- 
gramme audio-video-interactif (AVI) dans un r£cep- 
teur audio-video-interactif qui . recoit un flot de s 
paquets comprenant un repertoire et un pro- 
gramme audio-video-interactif ayant un identrfica- 
teur associe dans le repertoire, comprenant les 
stapes consistant k : 

u 

charger le programme audio-video-interactif 
dans une memoire (328) en reponse k la pre- 
sence du • programme audio-video-interactif 5. 
dans le f lot de paquets ; 

commencer I'execution (63) du programme is 
audio-video-interactif charge ; 
corrtrOI er si le flot de paquets contient un pro- 
gramme audio-video-interactif different du pro- 
gramme audio-video-interactif qui s'execute ; 6. 
et 20 
interrompre (65) et mini miser (67) les ressour- 
ces affectees k I' execution du programme 
audio-video-interactif lorsque I edit programme 
audio-video-interactif different dudit pro- 
gramme audio-video-interactif est detecte dans 2s 
le flot de paquets, et dans lequel la minimisa- 
tion comprend le retrait dudit programme 
audio-video-interactif qui s'execute de ladite 
memoire (328). 

30 

2. Precede selon la revendication 1, dans lequel 
retape d'interruption et de minimisation du pro- 
gramme audio-video-interactif qui s'execute com- 
prend les etapes consistant k : 

35 

suspendre ('execution du programme audio- 
video-interactif ; 

memoriser I'identificateur du programme 
audio-video-interactif dans un bloc de memoire 
; et 40 7. 

memoriser l_'6tat et I'environnement d'execution 
du programme audio-video-interactif au 
moment de la suspension de I'execution, dans 
ledit bloc de la memoire. 

45 

3. Precede selon la revendication 2, dans lequel 
retape de chargement du programme audio-video- 
interactif comprend les Stapes consistant k : 

charger un programme audio-video-interactif so 
en memoire ; 

rechercher, dans les blocs de memoire memo- 
rises precedemment, un bloc contenant un 
identificateur qui correspond k celui du pro- 
gramme audio-video-interactif charge ; et ss 
s'il existe un bloc de memoire correspondant, 
r6gler retat et renvironnement d'execution du 
programme audio-video-interactif charge k 



retat et I'environnement d'execution pour le 
programme audio-video-interactif correspon- 
dant memorise dans ledit bloc de memoire. 

4. Proc6d6 selon la revendication 3, comprenant, de 
plus : 

apres ladite etape de reglage, le maintien dudit 
programme audio-video-interactif charge dans 
un etat inactif jusqu'a I'activation par une 
entree d'utilisateur. 

Procede selon la revendication 4, comprenant, de 
plus, retape consistant k afficher un indicateur de 
programme interactif qui indique qu'un programme 
audio-video-interactif est charge mais ne s'execute 
pas. 

Proc6d6 pour commander I'execution du pro- 
gramme audio-video-interactif dans un recepteur 
audio-video-interactif qui recoit un flot de paquets 
comprenant un programme audio-video-interactif et 
des signaux d'execution, comprenant les etapes 
consistant k : 

charger le programme audio-video-interactif 
dans une memoire en reponse k la presence 
du programme audio-video-interactif dans le 
flot de paquets ; 

commencer i'execution du programme audio- 
video-interactif charge ; 
contrdler si le flot de paquets contient des 
paquets de signaux particuliers ; et 
arrSter I'execution, et d6charger le programme 
audio-video-interactif qui s'execute de la 
memoire en reponse k la detection d'un paquet 
de signaux particulier contenant un signal de 
fin d'execution. 

Procede selon la revendication 6, comprenant, de 
plus, les etapes consistant a : 

suspendre I'execution du programme audio- 
video-interactif en reponse k un signal de sus- 
pension d'execution dans le flot de paquets, 
dans lequel la suspension de I'execution com- 
prend la memorisation de retat d'execution du 
programme audio-video-interactif suspendu et 
le dechargement du programme audio-video- 
interactif de la memoire ; et 
continuer I'execution d'un programme audio- 
video-interactif suspendu precedemment en 
reponse k un signal de poursuite d'execution 
dans le flot de paquets, dans lequel la pour- 
suite de I'execution comprend le rechargement 
du programme audio-video-interactif suspendu 
precedemment k partir des donnees dans ledit 
flot de paquets et le prereglage des etats d'ex6- 
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cution avec les donnees memorisees lorsque 
le programme audio-video-interactif suspendu. 
prec6demment a ete suspendu. 

Procede selon la revendication 7,. dans lequel le s 
signal de suspension d'execution dans le flot de 
paquets est represente par des paquets de signaux 
de suspension d'execution repetitifs dans un inter- 
valle de temps de suspension, et le signal de pour- 
suite d'execution est represente par la cessation w 
desdits paquets de signaux de suspension d'execu- 
tion repetitifs. 
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